A datastore may be a repository for storing, managing, and distributing electronic data, and may store any of the data resources produced and/or utilized by an individual and/or an organization. Data resources may include files, documents, media (such as music and video), records, sensor data, and/or user profiles, or portions thereof. Data of the datastore may be stored in a database (e.g., a database management system, like MongoDB®, Riak®) and/or a file system (such as a hierarchical file system (HFS), network file system (NFS)). The data is stored within the datastore according to one or more data structures that define the physical arrangement of the data in a physical memory of one or more computers (e.g., servers) that are used to implement the datastore.
The datastore may include data resources that are proprietary, confidential, and/or private. For example, such data resources may include financial information, private communications, electronic medical records, or valuable trade secrets. A data resource that is protected by a security system may be referred to as a protected resource. The security system may require a user to be authenticated before the user can access the datastore and/or may require the user to be authorized before the user can utilize one or more of the protected resources of the datastore (e.g., use the protected resource on a device and/or manage a protected resource on a server). Specifically, an authentication process may be used to verify that the user is who they purport to be (e.g., validate the user's identity), while the authorization process may be used by the security system to ensure that the user is privileged to access a protected resource (e.g., download a video file, download a document, view personal information of the user profile). In some security systems, authorization may determine who has “access” to a particular protected resource.
For example, the authorization process may use an access control list (referred to as an ACL) to determine which users have permission to access a file in the file system or an individual field in the database application program. The access control list may also specify a limited set of allowed actions that the user can take on the protected resource (e.g., a read operation, a write operation, an execute operation, a delete operation). In attempting to limit access to the datastore and resolve permissions associated with access requests, the security system may use a significant number of systems external to the datastore. For example, the access control list may be an external system used by the security system. Once the data resource is accessed, a copy of the data resource may be made and distributed to (e.g., downloaded by) a device such as a smart phone, a piece of wearable technology like a smart watch, a desktop computer and/or a different server.
As the datastore increases in size, it may become increasingly difficult when using an external system to determine which data resources are protected by the security system and/or which permissions are associated with a particular protected resource. As a result, there may be oversights in defining security measures within the datastore. There may also be significant computing overhead to manage and utilize the external system. It may therefore be difficult to automatically and/or programmatically update the external system, which may prevent the security system from scaling to meet high demand of users of the datastore.
Complexity and/or overhead in defining and maintaining associations between the external system (such as the access control list) and the protected resources in the data structure of the datastore may prompt the organization to grant permissions in groups. For example, the security system may be used to define a group of users, to which permissions of a set of data resources are associated. As a result, a user of the group may be over-permissioned by having access to data that is unnecessary for the user's purpose, which may increase a security risk to an organization if the user (e.g., an employee) loses his or her identity credentials or takes actions against the interest of the organization. At the same time, the user may face the inconvenience that they are under-permissioned when they need to utilize a protected resource placed in a different group for which the user is not generally permissioned.
Once the copy of the data resource leaves the datastore, the copy may be outside the control of the security system. For example, once the protected resource is copied out of a first file system of a first computer and into a second file system of a second computer, the protected resource may generally be beyond the reach of the access control list of the first computer (in other words, it may no longer be “protected.”). Even where a file is encrypted, once the file is decrypted on the second computer the file may generally be outside the control of the first computer and the access control list of the first file system. While some additional security features may be able to be placed on files, the set of bites attached to the file may be able to be stripped off, defeating the security features. As a result, it may be difficult to monitor and/or control use of the data resource on a device: once the device obtains the data resource, the complete data resource may generally be used without restriction (including further copying and/or dissemination). Further, any data about a use of the data resource on the device may be difficult to obtain, precluding complete audit records and limiting analysis and insight.
As a result, the security system may have limited capacity to control and secure the private and confidential data resources stored in the datastore. The authorization process may provide simple access control with a small set of permissions such as read, write, delete and execute permissions. The security system may also use systems that may be external and distinct from the datastore to define permissions over data resources within the datastore, and such a system may be complex and difficult to scale. The security system may only be able to regulate mere access to protected resources. Once a protected resource leaves a domain of the security system (e.g., leave a particular hierarchical file system and access control list), the protected resource may be out of control and out of sight.